…uage module

This commit implements the core logic for plugin-specific output directories in the JavaScript language module, enabling each JS plugin to output generated code to custom locations while maintaining backward compatibility and robust error handling.

Key implementation details:

1. Plugin Module Configuration Updates:
   - Modified grpcWeb, twirp, and tsProto module imports to pass plugin-specific outputPath if configured, falling back to parent outputPath
   - Updated ES module configuration to use explicit null checking for outputPath inheritance

2. Protoc Plugin Arguments:
   - ES modules: Updated --es_out argument to use esOutputPath variable instead of hardcoded outputPath
   - Maintained existing logic for other plugins while adding outputPath flexibility

3. Directory Creation Logic:
   - Enhanced initHooks to create plugin-specific directories when custom outputPath is configured
   - Added proper null checking to prevent directory creation failures
   - Maintained existing directory structure for backward compatibility

4. Package.json Generation:
   - Updated ES modules package.json generation to use correct outputPath
   - Ensured package.json is created in the actual output directory for ES modules

5. Error Handling and Safety:
   - Implemented robust null checking throughout the module
   - Added fallback logic to prevent runtime failures when outputPath is not set
   - Maintained type safety with proper Nix expression evaluation

Technical implementation highlights:
- Uses Nix pattern for clean fallback logic when outputPath is null
- Leverages let expressions for computed output paths to avoid code duplication
- Maintains the composable plugin architecture while adding outputPath flexibility

This implementation enables complex JavaScript project structures where different code generation plugins can target separate directories, crucial for monorepos, microservices architectures, and projects with distinct frontend/backend code organization requirements.

The changes are fully backward compatible - existing configurations work unchanged, while new projects can leverage the enhanced output directory control for better code organization and build pipeline flexibility.

This commit removes generated protobuf output files that were inadvertently committed to the repository. These files are artifacts of code generation processes and should not be tracked in version control as they can be regenerated from source protobuf definitions.

Files removed:
- output/backend/proto/proto/api/v1/user_service.proto
- output/backend/proto/proto/common/v1/types.proto
- output/backend/proto/proto/external/v1/webhook.proto
- output/frontend/src/proto/proto/api/v1/user_service.proto
- output/frontend/src/proto/proto/common/v1/types.proto
- output/frontend/src/proto/proto/external/v1/webhook.proto

These files appear to be duplicates of protobuf definitions that exist elsewhere in the repository (likely in example directories or as source files). Keeping generated files in version control violates best practices because:

1. They can become stale if source protobuf files are modified
2. They increase repository size unnecessarily
3. They can cause confusion about which files are source vs generated
4. They may contain environment-specific artifacts

The proper approach is to:
- Keep only source .proto files in version control
- Generate output files as part of build/CI processes
- Use .gitignore to exclude generated directories
- Document generation processes clearly

This cleanup ensures the repository contains only source code and configuration, maintaining a clean separation between source and generated artifacts. The removed files can be regenerated using the appropriate Bufrnix commands when needed.

This commit adds the expected output files for the proto-copier example, which demonstrates Bufrnix's proto file copying functionality. These files serve as both documentation and validation that the proto copier works correctly.

Output structure added:
- output/backend/proto/proto/: Proto files copied for backend service consumption
  - api/v1/user_service.proto: Public API definitions
  - common/v1/types.proto: Shared type definitions
  - external/v1/webhook.proto: External integration APIs

- output/frontend/src/proto/proto/: Proto files copied for frontend development
  - Same structure as backend but in frontend-appropriate location

Key characteristics of this output:
1. **Filtered copying**: Only public APIs are included (internal/ and test/ directories excluded)
2. **Structure preservation**: Original directory hierarchy maintained
3. **Multiple destinations**: Files copied to both backend and frontend locations
4. **Clean separation**: No internal or test proto files in the output

This demonstrates the proto copier's ability to:
- Distribute proto files to multiple teams/services
- Apply filtering rules to exclude sensitive or irrelevant files
- Maintain directory structure for proper imports
- Support microservice architectures with shared proto definitions

The output files are committed as part of the example to:
- Provide immediate visual verification of functionality
- Serve as test fixtures for CI validation
- Document expected behavior for users
- Enable quick testing without running generation

These files are regenerated when the example is run, ensuring they stay current with any changes to the source proto files or copying logic.